討論有了結論，決定進入 propose 後，AI 就會開始準備 change 的規劃文件。不過，在寫 delta specs 以前，還得先確認：這次要改的功能，原本有沒有對應的規格？
例如正式 specs 已經有 auth，AI 卻用 authentication 建立另一份規格，就可能把同一個功能分開記在兩個地方。【Day - 9】看過，archive 會依照 capability 路徑更新正式 specs，所以名稱不同，最後就可能留下兩份規格。
因此，我想在 propose 準備 delta spec 時，就先確認這次該沿用既有名稱，還是真的需要新增 capability，不要等到 archive 才發現問題。
【Day - 10】看過 Spectra propose 會先搜尋正式 specs，讀取相關 capability 的 Purpose。我在 Speclink 保留這個作法，再要求 AI 把找到的規格與判斷理由寫進 proposal。如果仍然需要新增 capability，也要說清楚為什麼現有規格不適用。
假設需求寫的是「替登入流程加入 MFA」，AI 即使看到 authentication 這個說法，也應該先找到既有的 auth，確認它的 Purpose 已經涵蓋登入與驗證，再沿用 auth 建立 delta spec。如果現有 specs 真的都沒有涵蓋這項需求，才把它列為 New Capability，並在 proposal 裡說明為什麼需要新增。
實際使用時，這段通常是由 AI 自己完成。它會把掃描結果與判斷留在 proposal 裡，但不會特別停下來問我：「剛剛發現一個命名問題，要不要使用 auth？」只要既有規格已經足以判斷，它就繼續沿用正確的 capability 往下走。
光看 auth 這個名稱還是有點抽象，所以我請 Codex 準備了一個包含 auth 正式規格的示範專案，直接用 Speclink Desktop 打開來看：
AI 判斷功能應該放在哪份規格時，看的不只有 auth 這個名稱，還包含畫面中的 Purpose、requirements 與 scenarios。
AI 確認功能應該放在哪份規格後，就會準備建立 delta spec。如果它仍然用了正式 specs 裡不存在的名稱，負責寫入檔案的 CLI 能先做哪些確認呢？
AI 可以閱讀規格，判斷兩個名稱是不是在說同一個功能；CLI 則先檢查名稱有沒有完全相同。
正式 specs 已經有這個名稱，或目前的 change 已經宣告過，就可以繼續建立。如果兩邊都沒有，CLI 會要求明確加上 --new，才接受它是新的 capability。沒有加上時，就先停止寫入，並列出可能相關的名稱，讓 AI 回頭確認。
判斷順序可以看下面這張圖：
CLI 不知道 authentication 和 auth 是不是在說同一個功能。它只能先確認這個名稱是否存在；拒絕寫入後，再找出字面相近的名稱，附上來源與 Purpose，讓 AI 回頭讀規格、重新判斷。
不過，只查正式 specs 還不夠。我有時會同時處理多份 changes，其中一份可能已經規劃了新的 capability，只是還沒 archive，所以正式 specs 裡還找不到。如果沒有一起查看，另一份 change 就可能又替相同的功能取了不同名稱。
因此，CLI 提供建議時，也會查看其他尚未 archive 的 changes。找到相同或相近的 capability 名稱，就標出它來自哪個 change，並附上 Purpose 的第一行。AI 才能進一步確認：這兩份 changes 是在修改同一個功能，還是真的需要分成不同的 capabilities？
其他 changes 裡的名稱是提供給 AI 查找的線索，不表示這次就能直接使用新名稱建立檔案。這裡也只比對名稱，不會逐條檢查另一份 delta spec 的 requirements 是否在說同一件事。
假設正式 specs 已經有 auth，當我們替 add-mfa change 嘗試用 authentication 建立 delta spec：
speclink new artifact spec authentication \
--change add-mfa \
--stdin \
--no-color
CLI 沒有建立 specs/authentication/spec.md，而是直接回傳失敗：
Error: Capability 'authentication' is not in the canonical specs.
Similar existing names:
- auth (canonical): 管理使用者登入、驗證與 session 的既有行為。
To modify an existing capability, reuse its exact name.
If this really is a new capability, re-run with --new.
這裡不只是列出一個長得相近的名稱，還會標示它來自正式規格，並帶出 Purpose 的第一行。AI 可以根據這些線索重新判斷：authentication 其實就是既有的 auth，所以應該換回正確名稱，而不是再建立一份新的規格。
--new不存在於正式 specs 的名稱，不代表一定是錯的。這次需求也可能真的在加入全新的能力，所以 CLI 不能看到陌生名稱就永遠擋住。
因此，我在 Speclink 保留了 --new：AI 檢查過建議清單與相關 specs，確認現有 capabilities 都沒有涵蓋這次需求後，才用它明確宣告「這是一個新的 capability」。--new 只放行這次命名，原本的 delta spec 格式驗證與檔案覆寫保護仍然會繼續執行。
propose Skill 也要求先嘗試不帶 --new 建立規格。CLI 如果拒絕，AI 就回頭看建議：發現是同一項能力，就沿用正式 specs 裡的 capability 名稱；確認真的不同，才加上 --new 重跑。只要相關 specs 已經提供足夠資料，這段通常不需要再停下來問我。
加上 --new，只是確認要新增一個 capability，還得寫清楚這個功能負責哪些事情。這就是 Purpose 的用途。【Day - 9】介紹的 OpenSpec，以及【Day - 10】使用的 Spectra 2.3.1，當時都會等到 archive 建立正式 spec，才放入一段提醒之後補寫的 Purpose，還沒有真正說明功能的範圍。
我希望在準備規格時就把這件事說清楚，所以在 Speclink 裡，propose 確認要新增 capability 後，就要把 Purpose 一起寫進 delta spec，寫完再檢查。前面提過，Spectra 3.0.0 後來也改成在 propose 先寫好 Purpose。以 Speclink 為例，內容可以像這樣：
## Purpose
管理使用者登入後的 session，包括建立、續期、撤銷與失效，
並說明 session 逾時、使用者登出或權杖失效時，系統應該怎麼處理。
## ADDED Requirements
...
artifacts 都準備完成後，propose 收尾的 validate 也會先檢查這段內容。新 capability 缺少 Purpose、內容是空的或過於簡短，都會直接回報錯誤，讓 AI 在進入 apply 前先補好。修改既有 capability 時，正式 spec 已經有自己的 Purpose，delta 不需要重新寫一次，也不會用這裡的內容覆蓋原本的說明。
不過，前面的命名檢查都發生在 CLI 建立 delta spec 時。如果 AI 直接寫入檔案，沒有經過這個入口，還有機會發現相近的 capability 名稱嗎？
前面看到，validate 會先攔下新 capability 缺少 Purpose 的情況。到了 capability 命名這裡，我又讓它多檢查一件事：是不是已經有名稱相近的 capability。
【Day - 9】已經介紹過，validate 會檢查 change 與 specs 的結構；【Day - 11】則說明 Spectra 會在 propose 與 ingest 收尾時執行。我在 Speclink 也沿用了這個安排，所以即使有人直接寫入檔案，沒有透過前面的 CLI 指令建立檔案，propose 或 ingest 收尾時仍然有機會發現問題。
validate 發現 delta capability 在正式 specs 裡沒有同名規格時，會用前面同一套字面比對方式，找出正式 specs 與進行中 changes 裡的相近名稱。如果有結果，就留下 warning，提醒我們回頭確認。這一道不會自動改名，也不會直接讓整個驗證失敗，因為相近名稱仍然可能代表兩個真的不同的能力；即使沒有透過 CLI 建立檔案，這裡也能補上一個提醒。
把前面的作法放在一起，就是：Skill 先要求 AI 查規格、說明理由；CLI 在建立檔案時確認是否真的要新增；validate 再提醒可能重複的名稱。它們分別在不同時候幫忙檢查：
不過，CLI 與 validate 提供的建議，是從名稱的字面相似程度找線索。名稱差很多時，即使背後談的是同一項能力，也可能不會被列出來。
例如，auth 與 authentication 字面接近，比較容易被列為候選；login 和 auth 卻未必如此。它們可能在某個系統裡屬於同一項 capability，也可能一個只處理登入流程，另一個包含整套身分驗證；光看名稱沒有辦法直接決定。
名稱相近，只能提醒 AI 回頭看看，不能直接判定兩份規格重複。AI 還是要讀 Purpose 與 requirements，確認它們各自負責什麼；資料不足時，再問我們。加上 --new 也只是明確表示這次要新增，不表示這個判斷一定正確。
這些檢查沒辦法找出所有重複的規格，但至少在準備新增時，會先讓 AI 確認既有規格，並留下新增的理由，減少只是換個名稱就多建一份的情況。
確認功能該放在哪份規格，並透過 propose 準備好需要的規劃文件後，就可以進入 apply。不過，tasks 裡的工作都能交給 AI 嗎？完成後，除了打勾，還能留下哪些紀錄？接下來，我們就看看 Speclink 怎麼處理這兩件事吧！
iThome鐵人賽
看影片追技術